home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / iesg / iesg.92-03-26 < prev    next >
Text File  |  1993-02-04  |  12KB  |  342 lines
  1.  
  2.                      IETF STEERING GROUP (IESG)
  3.  
  4.                   REPORT FROM THE TELECONFERENCE
  5.  
  6.                        March 26th, 1992
  7.  
  8.          Reported by:
  9.          Greg Vaudreuil, IESG Secretary
  10.  
  11. This report contains
  12.  
  13.         - Meeting Agenda
  14.         - Meeting Attendees
  15.         - Meeting Notes
  16.  
  17. Please contact IESG Secretary Greg Vaudreuil for more information.
  18.  
  19.  
  20. Attendees
  21. ---------
  22.  
  23.     Almquist, Philip / Consultant
  24.     Borman, David / Cray Research
  25.     Chiappa, Noel 
  26.     Crocker, Dave / TBO
  27.     Crocker, Steve / TIS
  28.     Coya, Steve / CNRI
  29.     Estrada, Susan / CERFnet
  30.     Gross, Philip / ANS
  31.     Hinden, Robert / BBN
  32.     Hobby, Russ / UC-DAVIS
  33.     Huizer, Erik / SURFnet 
  34.     Piscitello, Dave/ Bellcore
  35.     Vaudreuil, Greg / CNRI
  36.  
  37. Regrets
  38.  
  39.     Davin, Chuck / MIT
  40.     Reynolds, Joyce / ISI
  41.     Stockman, Bernard / SUNET/NORDUnet
  42.  
  43.  
  44.  
  45. 1. Administrivia
  46.  
  47.    1.1 Bash the Agenda 
  48.    1.2 Approval of the Minutes
  49.         1.2.1 February 20th
  50.     1.2.2 March 5th 
  51.    1.3 Next Meeting
  52.  
  53. 2. Review of Action Items 
  54.  
  55. 3. Protocol Actions 
  56.  
  57.  3.1 The PPP Authentication Protocols 
  58.  3.2 PPP Link Quality Monitoring    
  59.  3.3 SNMP Authentication
  60.  3.4 BGP NEXT-HOP-SNPA Attribute
  61.  3.5 Interdomain Policy Routing
  62.  3.6 MD2, MD5 Documents
  63.  3.7 Multipurpose Internet Mail Extensions
  64.  
  65. 4. RFC Editor Actions
  66.  
  67.  4.1 HYBRID NETBIOS END-NODES
  68.  
  69. 5. Working Group Actions
  70.  
  71.  5.1 Network Access Server Requirements (nasreq)
  72.  
  73. 6. Technical Management Issues
  74.  
  75.  6.1 ROAD Follow-on
  76.  6.4 IDRP over IP 
  77.  
  78.  
  79.  
  80. MINUTES
  81.  
  82. 1. Administrivia
  83.  
  84. 1.1 Bash the Agenda 
  85.  
  86. The agenda was approved as written.
  87.  
  88. 1.2 Approval of the Minutes
  89.  
  90. 1.2.1 February 20th
  91.  
  92.    The IESG approved the Minutes of the February 20th teleconference
  93.    for public distribution.
  94.  
  95. 1.2.2 March 3rd
  96.  
  97.    The IESG deferred approval of the March 5th minutes.
  98.  
  99. 1.3 Next Meeting
  100.  
  101.    Eric Huizer has asked that the IESG consider moving its
  102.    teleconference time so that it no longer conflicts Thursday Evenings
  103.    with personal obligations.  The IESG was open to the suggestion, and
  104.    tasked Steve Coya to juggle schedules to find a new meeting time.
  105.  
  106. ACTION: Coya -- Poll the IESG and determine if there is a meeting time
  107. available for teleconferences other than Thursday 12-2 EST.
  108.  
  109.    The next IESG teleconference was scheduled for Thursday April 2nd
  110.    from 12-2 PM EST. This meeting will be a single topic meeting to
  111.    resolve the outstanding administrative issues relating to the
  112.    creation of IETF work items for making progress with Routing and
  113.    Addressing.
  114.  
  115. 2. Review of Action Items
  116.  
  117.    The actions items were not reviewed during this meeting.
  118.  
  119. 3) Protocol Actions
  120.  
  121. 3.1  The PPP Authentication Protocols
  122.  
  123.   The IESG reviewed the PPP Authentication protocols document.  This
  124.   document describes a framework and specific protocols for simple
  125.   password and more rigorous challange-response authentication.
  126.  
  127.    The IESG approved this document pending two events.  The document
  128.    itself needs work editorial work in several places to improve the
  129.    clarity and the document required the publication of the MD5 Message
  130.    Digest algorithm as an RFC before it can be referenced by this
  131.    document.
  132.  
  133. ACTION: Vaudreuil -- Send a recommendation to elevate the PPP
  134. authentication protocols to Proposed Standard as soon as 1) The MD 5
  135. message digest algorithm document is submitted to be published as an
  136. RFC, and 2) A new version of the Authentication Protocols document is
  137. submitted clarifying several editorial points.
  138.  
  139. 3.2  PPP Link Quality Monitoring
  140.  
  141.    The PPP Link Quality Monitoring document reflects a significant
  142.    redesign of the original mechanism outlined in RFC 1171.  This new
  143.    mechanism has been implemented and texted and reflects lessons
  144.    learned and has been tested and implmented.
  145.  
  146.    The IESG approved this document for Proposed Standard.
  147.  
  148. ACTION: Vaudreuil -- Send a recommendation to elevate the PPP Link
  149. Quality Monitoring document to Proposed Standard.
  150.  
  151. 3.3 SNMP Authentication
  152.  
  153.    The IAB has discussed the SNMP Authentication documents and has
  154.    asked the IESG for further discussion.  Two issues were raised.
  155.    First were some relatively minor technical errors which can be
  156.    easily corrected, and second, the documents do not appear to meet
  157.    the IAB's normal standard for quality writing.
  158.  
  159.    The IESG discussed both of these points.  On the first point; The
  160.    specific technical points were not clearly communicated to the IESG,
  161.    however the IESG expressed dismay at hearing these objections at
  162.    this late time, after a through public review and a last call
  163.    period.  The IAB is working directly with the authors to resolve
  164.    these points.
  165.  
  166.    The harder question for the IESG was the document writing style
  167.    itself.  The IESG recognizes the the quality of documents is quite
  168.    variable.  The IESG has had the practice of approving proposed
  169.    standard documents if there are no glaring technical errors, and the
  170.    document meets the requirements for formatting and gramatical
  171.    correctness. Reviewing documents for writing style and clarity is
  172.    difficult.
  173.  
  174. POSITION: As long as a Proposed Standard document is technically
  175. acceptable, the writing is readable to the extent necessary to
  176. implement from. and the document reflects a best effort given the
  177. limited resources of the IETF, the IESG will approve such a document.
  178.  
  179. 3.4 BGP NEXT HOP SNPA Attribute
  180.  
  181.    The IAB has discussed the BGP Next Hop SNPA Attribute and has asked
  182.    the IESG for clarifications on several points.
  183.  
  184.    The specific question the IAB raised concerns the behavior of the
  185.    attribute across different networking technologies, especially
  186.    across multi-media bridges.  The IESG discussed and agreed to ask
  187.    the working group to re-examine the intended scope of this
  188.    protocol.  The IESG also discussed the implications of operating a
  189.    protocol like the SNPA attribute across a multi-media bridge, and
  190.    concluded that this is not a real concern at this time.  Multi-media
  191.    bridges have not yet been architected into the system and many
  192.    protocols break across them, not just this one.
  193.  
  194. ACTION: Hinden -- Begin a dialogue with the the BGP working group to
  195. explore the intended scope of the BGP Next Hop SNMP Attribute.
  196.  
  197. 3.5 Interdomain Policy Routing
  198.  
  199.    The Interdomain Policy Routing Working Group has asked the IESG to
  200.    consider IDPR for Proposed Standard.  The IESG agreed that it is
  201.    appropriate to standardize IDPR according to the proceedures
  202.    documented in RFC 1264.
  203.  
  204.    A last call will be issued once the final version of the protocol,
  205.    as well as the required reports are submitted to the Internet Drafts
  206.    directories.  One of the reports that IESG has asked for is a
  207.    discussion on the interworking of IDPR with BGP in the Internet.
  208.  
  209. ACTION: Vaudreuil -- Send a last call for IDPR once the final version
  210. is posted as an Internet Draft.
  211.  
  212. ACTION: Hinden -- Communicate with the IDPR Working Group the need for
  213. updated documents and reports before approval for Proposed Standard.
  214.  
  215. 3.6 MD2, MD5 Documents
  216.  
  217.    Several Security related protocols reference the MD2 and MD5 Message
  218.    Digest Algorithms.  These algorithms are documented in Internet
  219.    Drafts that should be published as informational RFC's.  There is
  220.    new text for both of these documents.
  221.  
  222. ACTION: Vaudreuil -- After new text is submitted to the Internet
  223. Drafts, send a notification to the RFC Editor that the documents are
  224. ready to be published as RFC's.
  225.  
  226. 3.7 MIME
  227.  
  228.    The Internet Mail Extensions Working Group has submitted a revised
  229.    version of MIME to the Internet Drafts directory and has asked the
  230.    IESG to consider it for Proposed Standard. The new version reflects
  231.    the changes requested by the IESG.  The IESG has received an
  232.    objection from EUnet, a network con sortium analagous to UUnet.
  233.    They object to the separation of the Mnemonic character set proposal
  234.    from the main MIME standard.   The IESG discussed this objection,
  235.    but concluded that the specific objections could not be accommodated
  236.    in the current document due to rules for citations, but that the
  237.    functionality requested could still be achieved via registration of
  238.    the mnemonic character set with IANA.
  239.  
  240. ACTION: Hobby -- Send an IESG response to the EUnet objections.
  241.  
  242.    The IESG discussed the changes, and approved MIME for Proposed
  243.    Standard, providing that a second last call is issued and no new
  244.    serious issues are uncovered.
  245.  
  246. ACTION: Vaudreuil -- Send a second last call to the IETF list for MIME
  247. soliciting any objections to the changes in the current draft.
  248.  
  249. 4.0 RFC Editor Action
  250.  
  251. 4.1 NETBIOS over TCP
  252.  
  253.    Fredrick Noon was contacted by the IESG Secretary and was asked to
  254.    clarify the intended status for the protocol.  He has responded that
  255.    he would like the document to be entered on the standards track.
  256.  
  257. ACTION: Vaudreuil -- Send note to Postel taking the Netbios document
  258. into the standards process.
  259.  
  260.    The IESG discussed the need for community review, but was not able
  261.    to resolve the question of whether an IETF Working Group would be
  262.    the best place to review this proposal.
  263.  
  264. ACTION: Borman -- Do some intellegence gathering, determine the
  265. constituency, and determine whether a working group or a one-shot BOF
  266. is necessary for review of the Netbios over TCP document.  Determine if
  267. Noon is willing to chair a working group or BOF to review this
  268. protocol.
  269.  
  270. 5.0 Working Group Actiosn
  271.  
  272. 5.1  Network Access Server Requirements
  273.  
  274.    The IESG has reviewed the nasreq working group.  Steve Kent raised a
  275.    question of overlap between this group and others with similar
  276.    sounding charters which pointed out that the scope of the group is
  277.    not well defined.  A new charter which more clearly specifies the
  278.    work to be accomplished is needed.
  279.  
  280. ACTION; Hobby -- Work with the prospective chairman of the nasreq
  281. working group to refine the scope of the Working Group and generate a
  282. new charter.
  283.  
  284. 6.0 Technical Management Issues
  285.  
  286. 6.1 Routing and Addressing
  287.  
  288.    The ROAD group, chartered by the IAB has given its recommendations
  289.    to the IETF for future work in Routing and Addressing.  The IESG
  290.    began discussions on a workplan to solve the routing and addressing
  291.    issues facing the Internet.
  292.  
  293. 6.1.1  Class B Number Assignment
  294.  
  295.    The Class B numbers are being consumed at a high rate.  It is clear
  296.    that they will run out in the near future.  While the IETF works on
  297.    a plan for extending the class B address space, policies for the
  298.    assignment of network addresses need to be made.
  299.  
  300.    This IESG discussed several ideas including charging for the cost of
  301.    assigning and routing IP addresses, but did not reach resolution.
  302.    There was a clear sense that the IETF "ownes" this problem and that
  303.    work should begin on formulating assignment guidelines.
  304.  
  305. 6.1.2 Short Term Addressing
  306.  
  307.    There are two proposals on the table for resolution of the Class B
  308.    depletion problem, C-Sharp (C#), a creation of additional Class B
  309.    numbers, and CIDR, Classless Interdomain Routing.  Both proposals
  310.    appear to address the short term needs, but have relative advantages
  311.    and dis-advantages.  C# mostly solves the C# of B address problem
  312.    but does not address the aggragation of addresses necessary to
  313.    contain the routing table explosion.  The immediate need to work on
  314.    a single solution requires a choice of one of these proposals to
  315.    pursue.
  316.  
  317.    The decision on the choice of Cider vs C# depends on projections on
  318.    when the addresses will run out.  These numbers have not been made
  319.    available to the IESG.  The numbers used by the ROAD group in
  320.    crafting their recommenation for CIDR are statistically sensitive
  321.    projections and as such there is a reluctance to release the numbers
  322.    to a wider community.
  323.  
  324.    The IESG discussed the tension between the need to move forward
  325.    rapidly on this issue and the demands for openess.  This tension
  326.    results from the dual responsiblity of the IESG for both the
  327.    operational stability of the Internet and the need for complete and
  328.    accepted standards.
  329.  
  330.   The IESG will continue this discussion in a single topic
  331.   teleconference April 2nd.
  332.  
  333. 6.4 Dual IDRP
  334.  
  335.    An effort to begin work on Dual IDRP (ISO BGP) has begun in the noop
  336.    Working Group.  This work needs to procede in the Routing area, but
  337.    is not clear whether is should be in the IS-IS working group or a
  338.    new Dual IDRP Working Group.
  339.  
  340. ACTION: Hinden -- Find a home for the Dual IDRP work in the Routing Area.
  341.  
  342.